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LOGICDEL DE GENERATION DE CODK D> A PPLICATION INFORMATIOITE 
ET LANGAGE DE DESCRIPTION PE LOGICIEL 



5 DOMAINE TECHNIQUE 

La presente invention conceme un logiciel de generation du code infoimatique d'au 
moins une partie d*ime application infonnatique a partir d'une description de ladite partie de 
Tapplication infoimatique. L*invention conceme aussi un langage de description de logiciel, 
notarmnent du type langage objet de modelisation d'application infonnatique. 
10 Dans la pr6sente description, nous employons les termes suivants avec la sens indiqu6 : 

- « application infoimatique » : designe tout programme ou tout ensemble de programmes 

prevus pour fonctiomier conjointement, dont le but est de rendre des services k leurs 
utilisateurs ; une application est constituee de : 

- ses interfaces, c'est-4-dire, Tinteraction avec le monde exterieur a Tapplication 
15 (utilisateurs humains, autres systemes d'information), 

- de ses traitements, c'est-4-dire ses rouages internes, ses algorithmes, 

- et de ses doim6es, c*est-^-dire de toutes ses structures d'information stockees en 

m6moire vive ou sur support persistant, conune un disque dur. 

- « architecture technique » : il s'agit de Tensemble des technologies utilis6es pour r^aliser 
20 une application infonnatique, ainsi que des rdgles de repartition permettant d'affecter les 

differents parties de cette application sur ces differentes technologies et des modes de 
communications entre ces technologies. 

- « classe » : designe la notion de classe commun6ment manipul6e dans les formalisme de 

modelisation et langages de progranunation orients objet c'est-i-dire Tagregation de 
25 donn^es et de traitements (appeles respectivement attributs et m6thodes) destm6s k 
fonctionner ensemble dans une application infonnatique. 

- « client » : d6signe I'utilisateur de services qu'il ne d^tinit pas lui m&ne. Un client utilise les 

services mis a disposition par des serveurs. Par extension, on parle d'applications client, 
d'interfaces cUent, etc. 

30 - « code source » : texte ecrit dans un langage de programmation ou de description qui est 
ensuite compil6 en langage machine afin d'Stre ex6cut6 par une plate-forme infoimatique 
materielle, ou interprete par un environnement logiciel ou materiel d'interprdtation. 
- « code compil6 » : resultat de I'operation de compilation d'un code source. 
- « code » : designe indifferemment du code source ou du code compile. 
35 - « compilation » : action de traduction d'une description e:q>rim6e dans un langage de 
programmation vers le langage natif d'une plate-forme infonnatique mat&ielle, avant son 
execution par cette plate-forme infonnatique materielle. 
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- « serveur » : designe le foumisseur d'lin service. Les services mis a disposition par un 

serveur peuvent etre utilises par des clients. Par extension, on parle d 'applications serveur, 
d'interfaces serveur, etc. 

- « heritage » : relation attachant deux classes dont xme prraiiere herite d'une seconde et 
5 pennettant k la premise d'enrichir la definition de la seconde tout en conservant toutes les 

caract6ristiques de cette seconde classe. 

- « interface » : dans une application informatique, une interface est un ensemble de points 

d'6change qui pennettent a Tapplication de conmiuniquer avec le monde ext&ieur Q)ar 
exerople, d'autres applications ou des utilisateurs), et de lui presenter des services et des 
10 informations. 

- « IHM » : sigoifie Interface Homme Machine, et est synonyme d'interface utilisateur. 

- « interface utilisateur » : dans une application informatique, Tinterface utilisateur est une 

interface particuliere : c'est la partie d'une application dediee specifiquement k la 
communication a double sens entre cette application et ses utilisateurs. Ainsi, grace a 

15 riHM, Tapplication pr6sente les donn6es et informations trait6es, par exemple en les 
aflSchant graphiquement sur T^cran, et Tutilisateur saisit des donn6es et dtelenche des 
actions, par exemple gr&ce k des champs de formulaire, des boutons et des menus, au 
moyen du clavier et de la souiis. Ces EHM sont constitu6es de composants .imitant 
graphiquement I'apparence d'objets du monde r6el qui pennettent de reconna!tre les 

20 fonctions affichees correspondantes. Par exemple, les doim6es sont souvent affichees et 
modifiables dans un rectangle trace k r6cran, imitant les champs de fonnulaire papier, de 
meme les actions sont figiu*6es par un texte dans une boite rectangulaire en relief 
s'enfon9ant quand on cUque dessus, a Tinstar des boutons des appareils 61ectriques. L'lHM 
est constitute d'une partie statique et d'ime partie dynamique. La partie statique comprend 

25 tous les aspects graphiques que sont la mise en forme et la presentation de I'information. 
La partie dynamique quant k elle comprend tous ce qui permet k Tutilisateur de 
commander Tapplication et d'interagir avec elle, tels que les 6v6nements issus de 
p6riph6riques et la gestion de la navigation. 

- « Interpretation » : action de traduction d'une description exprim6e dans un langage de 
30 programmation vers le langage natif d'un ordinateur pendant son execution par 

I'ordinateur. 

- « langage de programmation » : formalisme permettant de decrire des actions destinees a 

Stre executees par im ordinateur. Ces descriptions sont soit ex6cut6es directement par 
I'ordinateur, lorsque le formalisme natif de I'ordmateur est utilis6, soit aprfes compilation 
35 ou interpretation. Une application informatique est d6crite en utilisant un ou plusieurs 
langages de programmation. 

- « moddlisation » : designe Taction de produire une description d'un objet k r6aliser, afin de 

servir de module a sa realisation effective. Cette action de mod61isation consiste souvent. 
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en informatique, a s'abstraire de certaines considerations propres a la realisation, telles que 
les technologies employees, les considerations techniques, et les langages de 
programmation utiUses. Cela permet de simplifier le travail de conception en r6duisant le 
nombre de concqjts a manipuler. 
5 - « modelisation abstraite » : est Tacte de representer les applications informatiques a reahser 
dans un fonnalisme indSpendant des technologies et des considerations techniques en se 
basant sur des concepts abstraits. 

- « outil de developpement logiciel » : ^>plication informatique pennettant de construire des 

applications infonnatiques. 

10 •^•« technologie » : element logiciel pouvant etre un composant d'une application informatique 
r6alis6e ou bien un 616ment intermediaire de son processus de realisation cormne par 
exemple un outil ou un langage de programmation. On regroupe sous ce terme entre autres 
k la fois les langages de programmation, les ateliers de developpement logiciels qui y sont 
associes, les composants logiciels qu'on peut assembler dans ime application, les services 

15 et ressources techniques xms k disposition par un environnement materiel ou logiciel et les 
protocoles de communication entre 616ments logiciels. 

- « generation de code » : d6signe la production automatique de code pour une {^plication 

informatique au moyen d'lm g6nerateur. EUe se fait k partir d'une description d'^plication 
logicielle foumie au g^6rateur et servant a piloter cette generation. Celui-ci, aprds analyse 

20 de cette description, construit le code attendu en sortie. Cette description peut-etre 
exprim6e dans un langage de plus haut niveau que celui dans lequel le code sera produit. 
Ainsi on fait souvent le choix d'un langage le plus proche possible de Texpression 
naturelle humaine soit sous forme gr^hique soit sous forme textuelle. Ainsi on peut 
exploiter le g6n6rateur sans avoir k connaitre le fonnalisme du langage de programmation 

25 utilise dans le code g6ner6. 

- « langage » : tons les formats de representations permettant de decrire tout ou partie des 

logiciels afin de contribuer directement ou indirectement k leur construction effective. 



TECHNIQUE ANTERIEURE 

30 Actuellement, les outils qui permettent de g6n6rer du code n'offrent cette possibilite que 

pour un seul langage de programmation a la fois ou un ensemble de langage k la structure et 
aux roles predefinis et figes. Cette limite vient du fait que le generateur de code est lie 
expUcitement dans sa structure mfeme k ce langage ou k cet ensemble de langages. Ainsi, 
lorsque Ton souhaite produire automatiquement du code pour une architecture technique 

35 quelconque comprenant plusieurs langages de programmation, on est generalraient oblig6 de 
foumir plusieurs descriptions en entree de plusieurs gSnerateurs de code. Cela revient k 
effectuer manuellement la repartition du code sur les technologies de rarchitecture technique. 
Ce cas se pr6sente lorsque rarchitecture technique de Tapplication k r6aliser comporte 
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plusieiirs technologies. Et c'est aujourd'hui le cas le plus fr6quent dans le cadre du 
developpement d'une ^plication informatique. 

Pour effectuer une generation de code, les generateurs de code existaats se fondent sur 
des descriptions de plus haut niveau que le niveau du code a produire. EUes reposent souvent 
5 sur des langages de mod61isation comme UML et lesdits gen&ateurs pennettent d'en generer 
le code dans un langage de programmation donn6. A titre d'exemple, I'outil Rational Rose® 
de la soci6te Rational est un des outils permettant de r6aliser une mod61isation abstraite d'une 
application informatique en utilisant UML. 

En ce qui conceme les langages, on pent les categoiiser sur un diagranune k deux 
10 dimensions comme illustr6 sur la figure 1. La premiere, I'^chelle verticale, repr6sente le 
caractere d'independance technologique du langage. EUe croit k mesure que les informations 
decrites grSce au langage imposent de moins en moins, du fait de leur forme, d'utiliser telle 
ou telle plate-foime technique ou fonctionnelle. La seconde, Techelle horizontale, repr6sente 
la facility qu*il y a ^ identifier automatiquement le r61e, la structure et le fonctionnement 
15 d'une application k partir de sa description faite dans un langage, c*est-a-dire la facilite 
d'analyse semantique automatique de Tapplication k partir de sa description. Dit encore 
autrement, il s'agit de la facility k convertir cette description dans une forme directement 
lisible par Thomme, pr6cisant le fonctionnement et le sens de cette application. Cette 6chelle 
croit a mesure qu'a la fois les langages : 
20 - ofifrent des notions de plus en plus nombreuses et riches avec lesquelles on pent 

decrire un service technique ou fonctionnel donnd de plus en plus riche en utilisant 
un nombre de ces notions de plus en plus faible, 

- imposent au programmeur I'utilisation de plus en plus exclusive de ces notions pour 
realiser cette description. 

25 On peut distinguer les differents types de langages suivants : 

- les langages de lere gteSration : langages machines (par exen^le : code binaire x86 
ou 68000) ; 

- les langages de 2teie g6n6ration : langages symboliques (par exemple : assembleur 
x86 ou 68000) ; 

30 - les langages de 3eme generation : langages proceduraux et langages objets (par 

exemple : Basic ou Java) ; 

- les langages de 46me generation : langages manipulant des notions agregees et 
classiquement pris en charge par des ateUers de g6nie logiciel d^di^s (par exemple : 
PowerBuilder ou Windev) ; 

35 - les langages de mod61isation abstraite (par exemple : UML ou Merise) ; 

- les langages de description ^ar exeniqple : HTML, WML). 

Les langages de premifere g6n6ration sont les langages de plus bas niveau. Les 
instructions qui les composent sont direct^ent comprehensibles par un processeur. Elles sont 
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elementaires et en nombre restreint. En pratique, elles consistent en des nombres (exprimes en 
binaire) codifiant les actions realisables par le processeur en interne ou bien en interaction 
avec son environnraient materiel. Ces langages sont intimement lies a Tenviionnenient 
materiel capable de les executer. Cette dependance technologique les place tout en bas de 
5 r^chelle de dependance technologique. En ce qui conceme Tanalyse semantique automatique, 
celle-ci est pratiquement impossible du fait du caractere el6mentaire des instructions 
disponibles. En eflfet, la moindre operation a laquelle un hximain pourrait donner xme unite de 
sens pent necessiter plusieurs centaines d'instmctions exprimees en langage machine. Ceci 
justifie le placement de ces langages tout en bas de Tfichelle de facilite d' analyse semantique. 

10 Les langages de deuxifeme generation sont apparus pour pennettre aux programmeurs de 

ne plus utiliser directement les codes binaires des langages machines. En lieu et place de ces 
codes, les programmeurs ont pu utiliser des symboles plus directement compr6hensibles par 
rhonune. N6anmoins, ces langages symboliques restent des langages d'aussi bas niveau que 
les langages de premiere generation, et seule la designation des operations 61ementaires du 

15 langages change de forme (passant du binaire k une description alphanumerique). En eflfet, 
leur foimalisme est en bijection directe avec les codes binaires des langages de premiere 
generation. lis sont done, comme ces demiers, plac6s tout en bas de Techelle d'ind6pendance 
technologique. En ce qui conceme Tanalyse semantique automatique, celle-ci est 
pratiquement impossible sans disposer d'un analyseur d*une intelligence au moins egale k 

20 celle du programmeur ayant r6alis6 la description de cette application dans ce langage. En 
effet, le formalisme est de si bas niveau que les seuls elements qui pourraient porter une 
information de sens fonctionnel ou technique pourraient etre inclus dans les commentaires. Or 
le formalisme n'offre aucun cadre fonctionnel ou technique structure, ce qui interdit de les 
exploiter pour toute analyse d6terministe. 

25 Les langages de troisidme g6n^tion sont apparus pour pemiettre de d&rire une 

application informatique ind^pendamment du materiel qui exploitera cette description pour 
ex6cuter Tapplication en question et pour doimer accds k des operations de base plus 
complexes que celles des langages de premiere et deuxiteie g6n6ration. N6anmoins, mSme si 
le formalisme et la syntaxe sont abstraits du materiel, les possibilites de description qu'offrent 

30 ces langages sont intimement liees k rehvironnenient technique qui sera utilis6 pour executer 
la description effectu6e. Ces langages constituent done un premier progr^s d'independance 
technologique qui permet au programmeur d'ignorer la maniere dont les fonctions de bases 
foumies par le langage sont mise en oeuvre sur la plate-forme technique cible, mais cela ne 
disponse pas le programmeur de devoir agencer ces fonctions de base d'une certaine manifere 

35 afin de prendre en compte les sp6cif[cit6s de cette plate-forme. En ce qui conceme la facility 
d'analyse s6mantique automatique, les langages de troisifeme g6n6ration constituent 
6galement un progr^s car ils ofGrent un cadre structure pour certains services techniques ou 
fbnctionnels notamment sur la structure des routines algorithmiques et sur la structure des 
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donnees manipulees. Neanmoins, ils offi-ent souvent Is possibilite de s'extraire ou de 
contoumer le cadre qu'ils foimiisseut pour d6crire xm service donn6. Cependant, ce niveau 
d' analyse ne peut depasser le niveau de complexite des fonctions de bases foumies par le 
langage, et il est degrade par cette possibilite de contoumement. Ainsi, pour constituer des 
5 unites de sens permettant d'inteipreter le fonctionnement de T application decrite, il faut 
rintervention d*un humain ou un outil d'analyse fond6 sur TinteUigence artificielle qui 
d^passe ce que Ton salt faire aujourd'hui. 

Les langages de quatridme generation (LAG) sont coi:q)les a des outils commun6ment 
appel6s AGL (Atelier de G6me Logiciel). Ce maiiage est si fort qu^on a coutume d'employer 

10 indifiFeremment Tun ou Tautre des deux tennes L4G ou AGL. Us sont nes d'une envie de 
CE^italisation concemant la creation de composants techniques, Ces AGL, partant du principe 
que la plupart des applications peuvent Stre construites par assemblage et param^trage de 
composants generiques, proposent une large palette de composants predefinis qu'il suffit de 
parametrer et de faire communiquer entre eux. Ces AGL sont tons lies a un langage technique 

15 specifique qui, comme les langages de troisieme generation, offre des possibilites limit^es par 
Tenvironnement technologique d*ex6cution duquel ils d^endent Cette limite place ces L4G 
au meme niveau d'independance technologique que les langages de troisieme g6n6ration. Par 
contre, en ce qui concsme la facilite d'analyse s6mantique automatique, celle-ci est supSrieure 
a tous ceux cit6s pr6c6demment. En efiTet, les AGL imposent strictement au programmeur la 

20 structure permettant de d^crire un service, technique ou fonctionnel. L' analyse semantique 
automatique peut done se reposer sur un determinisme parfait pour deceler ces services, avec 
la limite que le service identifi6 est associe a une realisation specifique a une plateforme 
technique imique, et n'est pas un service generique. Cette analyse ne peut done pas toujours 
pr6sumer de Tintention fonctionnelle du programmeur, mais elle peut toujours determiner son 

25 intention technique. 

Les langages de mod61isation abstraite sont n6s d'lme envie de description des 
applications ind^pendante de tout caractere technologique. Us se sont concentres sur les 
aspects algorithzrdques et de structure des donn6es. lis sont utilises pour d^velopper des 
applications en deux phases : la premiere conceme la creation d'lm modMe et la seconde la 

30 g6n6ration automatique du code dans im langage (la plupart du temps un langage de troisieme 
generation). Cette capacite de creer un modele ind6pendant des technologies pour la plupart 
des services a d6crire dans une application informatique nous fait le placer au dessus des 
autres langages que nous avons cit6s jusqu'^1 present sur r6chelle de Tindependance 
technologique. Cependant, pour pouvoir generer une application complete, il est 

35 indispensable, lorsqu'on utilise ces outils, d'inclure dans le module des liens avec les 
616ments de base du langage de troisieme generation qui sera finalement utilise, ce qui rend in 
jSne le moddle dependant de cette technologie. Enfin, il est necessaire de decrire I'application 
informatique qu'on modeiise d'une fa9on particuliere selon la configuration de Tarchitecture 
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technique, ce qui rend le modele dependant de celle-ci. En ce qui conceme la facilit6 
d'analyse s^mantique automatique, celle-ci est 6quivalente a celle obtenue par Tutilisation 
d'un langage de troisieme generation car les iangages de modelisation abstraite offirent un 
cadre structure poxir decrire certains services fonctionnels. L' analyse semantique automatique 
5 des modeles reste ainsi, du fait de la manipulation de notions de bas niveau et tr^s abstraites 
(classe, relation, methode, collaboration,...), incapable d'identifier automatiquement des 
services complexes techniques ou fonctionnels particuliers, sans intervention humaine ou sans 
module d'inteUigence artificiel d6passant P6tat de Tart actuel. 

Les Iangages de description sont fondes sur une syntaxe d6finissant de manidre fig6e les 

10 616ments informatiques qu'on peut d6crire en les utilisant. Comme les Iangages de 4^me 
generation, lis dfifinissent des notions de plus haut niveau qui sont destinees a etre assemblies 
pour former une description. Le sujet de cette description est souvent graphique et est 
notamment utilis6 en informatique pour decrire une interface homme machine. 
Historiquement, ils servaient i mettre en forme du texte, avant impression ou affichage a 

15 Tecran, Les 61ements qu'ils permettent de decrire sont statiques. Poiir introduire du 
dynamisme, ces Iangages sont parfois associis k nn langage de troisifeme generation. lis ne 
sont pas destine a permettre la production d'une ^plication. Leur prise en charge repose sur 
des outils appel6s navigateurs, qui les inteiprfetent pour efiPectuer, ce qu'on ^pelle le rendu de 
leur description, c'est*^-dire la transformation de I'information contenue dans le langage de 

20 description ainsi que ce denuer le pr6voit d^apr^ sa specification. Concemant I'independance 
technologique, ils permettent dans le cadre des capacites du langage de faire afficher leur 
description sur n'importe quelle plate-forme mat6rielle et logicielle, mais ils imposent une 
architecture technique particuliere, basee sur Texistence d'un outil de rendu. Par centre, en ce 
qui conceme la facility d'analyse semantique automatique, elle est au niveau de celle des 

25 L4G, car elle est fond6e^ comme eux sur une structure contraignante de services predefinis, 
mais imposant une mise en oeuvre technique particuliere. 

EXPOSE DB L'INVENTION 

L'invention vise k faciliter le developpement des applications informatiques et k 
30 permettre que ce d6veloppement s'effectue de fa9on plus rapide en comparaison de Tart 
anterieur. Elle vise aussi k rendre plus fiable a la fois T application informatique developpee et 
le deroulement du developpement de Tapplication informatique. Elle vise encore k faciUter la 
r6utiHsation des d6veloppements realises pour ime application informatique par exemple pour 
le developpement d'une autre application ou encore pour adapter Tapplication informatique a 
35 une nouvelle architecture technique. 

A cette fin, la prisente invention propose un logiciel de generation du code informatique 
d'au moins une partie d'une application informatique, dans lequel le logiciel genere ledit code 
informatique k pardr d'une description de ladite partie de 1' application informatique en 
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repartissant ladite desGiiption entre plusieurs senerateurs de code en fonction de regies de 
repartition modifiables, chaque generatenr de code traduisant la partie de ladite description 
qui Ini est foumie, pour foumir au moins une partie dudit code informatique dans un langage 
respectif. Ainsi, les regies de repartition peuvent avantageusement correspondre a 
5 rarchitecture technique qui mettra en oeuvre Tapplication informatique. Bien entendu, il est 
parfaitement envisag^ble d'adresser une meme partie de la description a plusieurs 
g6n6rateuTs de code diff6rents, par exenq)le si Ton souhaite g&i6rer simultanement le code 
informatique de Tapplication informatique pour plusieiurs architectures techniques difG§rentes. 
Les revendications d6pendantes ddfinissent des modes de r^isation pr6f6r6s du logiciel selon 

10 rinvention. Selon un autre aspect, Tinvention propose aussi un langage de description de 
logiciel, notamment du type langage objet de modelisation d' application informatique, 
organise en classes permettant de definir des premieres classes donnant acces a des services 
techniques ou fonctionnels k foumir par les plates-formes informatiques materielles et 
logicielles recevant T application informatique, dans lequel lesdits services ne peuvent pas §tre 

15 definis par ledit langage, et les autres classes ne peuvent acceder a un quelconque de ces 
services techniques ou fonctionnels que par rinterm6diaire desdites premieres classes. 

Selon encore im autre aspect, Tinvention propose un logiciel permettant de construire 
graphiqiiement ou textaellement un modele d' application informatique, notamment un module 
d'inter&ce homme-machine d'^plication informatique et de foumir une description du 

20 modele dans le langage de description de logiciel selon rinvention. 

D*autres caract6ristiques et avantages de rinvention ^paraitront a la lecture de la 
description qui suit d'un mode de realisation pref6r6 de rinvention, donn6e k titre d'exemple 
et en r6f6rence au dessin annexe. 

25 DESCRIPTION SQMMAIRE DES DESSINS 

La figure 1 iUustre sch6matiquement la position du langage selon rinvention par 
rapport a Tart ant6rieur en terme de richesse de description et de facilit6 d' analyse semantique 
automatique d'une part, et en terme d'ind6pendance technologique. 

La figure 2 illustre un exemple generique d' architecture technique. 
30 La figure 3 illustre un exemple de firagment d'architecture technique r^elle pouvant 

servir a realiser une application intranet HTML / JSP. 

La figure 4 est un schema iUustrant le fonctionnement d'un generateur de code 
architectural selon rinvention. 

35 MANIERES PREFEttBES DE REALISER L'INVENTION 

Nous d6crirons d'abord la manidre pr6f6r6e de realiser le logiciel de g6n6ration de code 
selon rinvention avant de dSciire celle du langage de description de logiciel. 
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1) Le logiciel de generation de code 

Par commodite, nous designerons par la suite le logiciel de generation de code selon 
rinvention par gen6rateur de code architectural. En effet, nous parlerons dans la suite de 
generation de code architecturale, car il s'agit de generer du code pour une architecture 
5 technique dans son ensemble, c'est-a-dire de repartir le code produit sur plusieurs 
technologies grace a des generateurs de code chacun responsable d'une technologie de 
rarchitecture. 

La generation de code architecturale est realis^e par le gen6rateur de code architectural 
qui pennet automatiquement d' analyser une description d' ^plication infonnadque, puis de 
10 repartir automatiquement ses elements constitutifs, afin d'en gen6rer le code^ en fonction de la 
description d'une architecture technique qui definit les choix a effectuer pour obtenir cette 
repartition sur di£f6rents generateurs de code et adaptateurs d'interface entre technologies, 
chacun prenant en charge une technologie particuli&re. 

Le generateur de code architectural comprend les modules suivants : 
15 - un analyseur de description d'application capable d'analyser des fichiers de 

description d' implications logicielles exprim^s dans un format de description d'^plication, 

- un analyseur de description d* architecture capable d'analyser des fichiers de 
description d' architecture technique dans un format de description d'architecture, 

- un filtre d'espace technologique, 
20 - des gen6rateurs de code, 

- des adaptateiurs serveur, 

- des adaptateiurs cUent, 

- un comparateur, 
-unrepartiteur, 

25 - un coordinateur. 

Nous allons d^crire successivement chacun de ces elements ainsi que le fonctionnement 
du generateur de code architectural. 

1.1^ Format de description d'application 
30 Ce format est choisi pour pemiettre de decrire les constituants de Tapplication 

informatique dont on cherche aproduire le code grace au generateur de code architectural. 

n peut avantageusement s'agir du langage de description de logiciel selon Tinvention 
plus particuUerement decrit au point 2). Neanmoins, d'autres formats peuvent etre utilises. 



35 1.2) Analyseur de description d'application 

L' analyseur de description d'application est prevu pour traiter des fichiers de 
description d'applications logicielles exprimes dans le format defini au point 1.1). II verifie 
que les fichiers qu'on lui transmet sont conformes k ce format et, k defaut, il emet une erreur. 
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n identifie. sans perte d*informations necessaires k la realisation de Tapplication, les 
61ements, enuin6r6s ci-dessous, a partir de ces fichiers puis les en extrait. Ces elements 
constituent alors une representation decomposee de la description de Tapplication destinee a 
etre transmise a d'autres modules. Si le format de description d'appUcation le necessite, il 
5 peut etre fait appel a des fichiers extemes tels que des bibliotheques pour completer cette 
analyse. Une description d' application effectuee en Java par exemple, utilise des classes du 
langage dont la definition ne fait pas partie de la description d'application mais se trouve dans 
des bibliotheques extemes. Ces biblioth^ues sont alors utilis6es k Tanalyseur de description 
d'application pour rep6rer que la classe qu'il est en train d'analyser est une classe du langage. 
10 Les elements en question sont : 

- une liste de classes dont chacune contient, le cas echeant, la liste de ses attributs types 
et la liste de ses methodes ainsi que leur signature typ6e totalement definie et le cas echeant, 
leur definition sous la forme de la sequence de commandes et operations qu'elle execute. On 
peut eventuellement y ajouter des liens vers d'autres classes dont la classe consideree herite, 

15 si cette notion d'h^ritage est introduite, 

- la liste des d6pendances entre classes, noises en relation pr6cis6ment avec le point de 
chaque classe oil ces d^pendances trouvent leur origine et leur cible. Chaque d6pendance 
represente un lien de dependance entre deux classes diff6rentes. Dans cette d6pendance, on 
consid^re que la classe qui est dSpendante de Tautre est la classe client. La classe dont la 

20 classe client est d6pendante est la classe serveur. 

La decomposition de la description de Tapplication issue de Textraction de ces elements 
est exprimee dans un format interne au generateur de code architectural. Ce format est partag6 
par tous les modules qui en ont besoin. 



25 1.3) Format de description d' architecture 

Ce format est pr6vu pour d6crire rarchitecture technique sur laquelle sera r6parti le 
code produit. Ce format permet de definir : 

- des espaces technologiques : il s*agit d'ensembles, munis chacun d'un identifiant, 
constitues du regroupement des 616ments suivants : 
30 -de la r6f6rence a un generateur de code (par son identifiant unique), ce 

generateur supportant une technologic donnee qui produira le code de 
Tapplication pour cet espace technologique, 

- d*un jeu de paramdtre de fonctionnement, c'est-a-dire ime liste de valeurs 
servant i param6trer le fonctionnement de ce g6n6rateur de code (tel que defini 

35 au point L6), 

- et d'un jeu de paramdtres de filtrage, c'est-i-dire une liste de valeurs destines 
au filtre d'espaces technologiques (defini au 1.5) afin de permettre k ce dernier 
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de verifier si une classe (au sens du point 1.2) est censee ou non Stre prise en 
charge (au sens du LIO) par cet espace technologique. 

- ses associations entre des adaptateurs et des dependances orientees entre espaces 
technologiques : pour chaque dq)endance orient6e d*un espace technologique envers un autre 
espace technologique, on affecte un adaptateur serveur et un adaptateur client. La d6pendance 
est orientee selon le sens defini par les roles dans cette dependance aUant de T espace qui est 
dependant vers T espace dont il depend. Dans cette orientation, on considere que T espace qui 
est dependant est I'espace client et que I'espace dont il depend est I'espace servexir. 

Le sch6ma de la figure 2 illustre un exemple g6n6rique d' architecture technique. 
Le schema ci-dessus montre 3 espaces technologiques (El) (E2) et (B3) dans lequel : 

- I'espace (El) est pris en charge par le g6nerateur de code (Gl) et est dote de 
ridentifiant unique (ID-El), du jeu de parametres de fonctionnement (Fon-Ela) et 
(Fon-Elb) et du jeu de parametres de filtrage (Fil-Ela), (Fil-Elb) et (Fil-Elc). 
L' espace (E2) est pris en charge par le generateur de code (G2) et est dot6 de 
ridentifiant unique CID-E2), du jeu de parametres de fonctioimement (Fon-E2a) et du 
jeu de parametres de filtrage CFil-E2a) et (Fil-E2b). L' espace (E3) est pris en charge 
par le g6n6rateur de code (Gl) et est dot6 de ridentifiant unique (ID-E3), du jeu de 
parametres de fonctionnement (Fon-E3a) et (Fon-E3b) et du jeu de parametres de 
filtrage (Fil-E3a), (Fil-E2b), (Fil-E2c) et (Fil-E2d). 

- toute dependance d'un element d' application piis en charge par (E2) envers un 
616ment d'^Ucation pris en charge par (El) est prise en charge par I'adaptateur client 
(Acl) et Tadaptateur serveur (Asl). Toute dependance d'un 616ment d'appUcation pris 
en charge par (El) envers un element d' application pris en charge par (E2) est prise en 
charge par Tadaptateur client (Ac2) et par Tadaptateur serveur (As2). Toute 
dependance d'xm element d'appUcation pris en charge par (E2) envers xm el6ment 
d'appUcation pris en charge par (E3) est prise en charge par Tadaptateiu- client (Ac3) 
et par 1' adaptateur serveur (As3). 

La figure 3 pr6sente un exemple de firagment d'architecture technique r6elle pouvant 
servir a reaUser une application intranet HTML / JSP. 

1 .4) Analvseur de description d'architecture 

L'analyseur de description d'architecture traite des fichiers de description d'architecture 
technique exprimes dans le format defini au point 1.3. 

II verifie que les fichiers qu'on lui transmet sont conformes a ce format, et a defaut il 
6met une erreur. 

n identifie, sans perte d'infomiations n6cessaires k la realisation de TappUcation, les 
elements, enumeres ci-dessous, k partir de ces fichiers puis les en extrait. Ces elements 
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constituent alors line representation decomposee de la description de rarchitecture dcstin6e a 
Stre transmise i d'autres modules. Les el6ments en question sent : 

- ia liste des espaces technologiques (identifiant unique, gen6rateur de code et jeux de 
parametres). 

5 - la liste des couples d' espaces technologiques client et serveur, et de leurs couples 

d'adaptateur cli^t et serveur associes. 
La decomposition de la description de rarchitecture issue de I'extraction de ces 
^16ments est exprim6e dans un format interne au g^n^rateur de code architecturaL Ce format 
est partage par tous les modules qui en ont besoin. 
10 L'analyseur de description d' architecture verifie que rarchitecture decrite est coh6rente 

avec les capacites des divers generateurs de code et adaptateurs clients et serveurs qui y sont 
mentionn^s : 

- il v6rifie que le jeu de parametres de filtrage de chaque espace technologique est 
compatible avec le jeu de parametres de filtrage des generateurs de code associds, en se 

15 reposant pom cette verification sui les services rendus par le filtre d' espaces technologiques 
(tels que d6crits au point 1.5) ; 

- il v6rifie que les adaptateurs client et serveur mentionnfe sont bien compatibles avec la 
technologie prise en charge par le g6n6rateur de code de I'espace technologique auquel 
ils sont eux-memes associes ; 

20 - il verifie aussi que les adaptateurs client et serveur sont compatibles entre eux ; 

- il pent aussi verifier, si les generateurs de code sont param6trables, que le jeu de 
parametres de fonctionnement de chaque espace technologique de rarchitecture 
correspond ^ des parametres references du generateur de code en question. 

n verifie aussi que pour un couple de deux espaces technologiques donnes client et 
25 serveur, il n'y a qu'un seul couple d'adaptateurs client et serveur associe dans la description 
de rarchitecture. Ces verifications sont effectuees afin d'6viter les ambiguXtes de repartition 
des dependances entre classes sur les adaptateurs. 



1.5) Filtre d^espaces technologiques 
30 Ce module utilise un jeu de parametres de filtrage comme la definition d'lm ensemble 

de classes. Pour im jeu de parametres de filtrage donne, il determine, pour toute classe, si elle 
appartient ou non k rensemble de classe defini par ce jeu de parametres de filtrage. Enfin, il 
foumit deux services fondes sur les jeux de parametres de filtrage : 
-le filtrage des espaces technologiques ; 
35 - la verification de rinclusion de deux jeux de parametres de filtrage. 

Le filtrage des espaces technologiques consiste, k partir d'lme liste d'e^ace 
technologique et d'une classe, k renvo>^r la liste des espaces technologiques pour lesquels la 
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classe en question appartient k Tensemble de classe defini par le jeu de paramdtres de filtrage 
associes a ces espaces technologiques. 

La notion d'inclusion de deux jeux de parametres est definie comme suit : soient deux 
jeux de parametres de filtrages Jl et J2, Jl est inclus dans J2, si, pour toute classe C 
5 appartenant k Tensenible defini par Jl, C appartient a I'ensemble defini par J2. 

1.6) G6ti6rateurs de code 

Les generateurs de code sont des modules du genSrateur de code architectural capables 
de produire du code pour une technologie particuli^e qui peimet de d6crire des algorithmes, 
10 Leur r6Ie est de produire le code correspondant k une classe k partibr de la d6finition de 

celle-d, de ses dependances avec d'autres classes. Dans le cas de d^pendances extemes d'lme 
classe avec d'autres classes prises en charge dans le mSme espace technologique, le code 
correspondant aux interfaces de cette classe avec ces autres classes est g6ner6 par ces memes 
g6n6rateurs de code. Dans le cas de dependances extemes de cette classe avec d'autres classes 
15 prises en charge dans des espaces technologiques dififerents, le code des interfaces de cette 
classe avec ces autres classes n'est pas gen6r6, mais les g6n6rateurs de code font figurer dans 
le code de cette classe une marque qu'ils choisissent, dite marque de localisation, permettant 
de retrouver I'endroit precis du code ou cette dependance sera traitee. 

Si la technologie qu'ils prennent en charge le n^cessite, les geneiateurs de code 
20 produisent les fichiers n6cessaires pour contenir le code produit. Dans tovis les cas, ils 
renvoient des r6ferences d'acces permettant d'acceder au code produit. 

Les gen6rateurs de code sont munis d'un identifiant unique qui permet de les designer 
de fa9on absolue dans la description de T architecture technique. 

ns sont pr6vus pour foiunir un jeu de parametres de filtrage qui definit Tensemble de 
25 classes (au sens du point 1 .5) dont ils peuvent produire le code. 

ns presentent aussi optionnellement une liste de parametres et les moyens de d6finir la 
valeur de ces parametres afin de qualifier Tenvironnement materiel et logiciel dans lequel 
cette technologie est ex6cut6e et de d6finir ainsi plus finement si n6cessaire Tespace 
technologique et les conditions de la generation de code. 
30 Un parametre de fonctionnement pent par exemple gtre le repertoire dans lequel seront 

stock6 les fichiers source genere. Un autre exemple pent etre le choix de la version du 'jdk' k 
utiliser dans le cas de Tutilisation d'un generateur de code Java, 

1 .7) Adantateurs serveurs 
35 Les adaptateurs serveurs permettent de generer du code dans un ou plusieurs espaces 

technologiques donnds. Ce code pent etre integre au code produit par un gen6rateur de code, 
Ce code joue le rdle d'interface serveur assurant la communication entre deux classes 
impliquees dans une dependance. Ce code s'integre au code qu'a produit un generateur de 
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code pour la classe serveur inipliqu6e dans cette d6pendance. Le code pradxiit par cet 
adaptatexir serveur permettra au code produit par un adaptateur client, integre au code qu'a 
produit un generateur de code pour la classe client de cette dq^endance, de s*interfacer avec 
lui. 

5 Les adaptateurs serveiirs sont numis d'un identifiant unique qui pennet de les d6signer 

dans la description de T architecture technique. 

Us indiquent dans quelle categoric d*interfaces ils se classent. Ces categories 
d'inter&ces servent a d^tenniner la compatibilite de ces adaptateurs serveurs avec des 
adaptateurs clients. Elles sont d6jGnies librement par les adaptateurs serveurs et peuvent 8tre 
10 partag6es par plusieurs adaptateurs serveurs dijfferents. 

Parmi les categories d'interface que peuvent d6finir les adq)tateurs, on pent citer par 
exemple CORBA® et RMI ®. 

Les ad^tateurs serveurs indiquent quels sont le ou les generateurs de code dont ils sont 
capables de modifier le code produit pour y inserer le code de leurs interfaces serveurs ou de 
15 produire du code d'interfa9age exteme au code produit par ce ou ces generateurs de code. 

Les adaptateurs serveurs produisent le code d'interface serveur a partir d'une 
d6pendance, des classes impliqu6es dans cette d6pendance et des r6f6rences d'acc^s au code 
produit pour ces classes par les g6n6rateurs de code correspondants k cette dSpendance. 

Les adq)tateurs serveurs repoivent de preference un signal de fin de transmission de 
20 requdte de g^Sration de code, leur indiquant qu'ils n'en recevront plus d'autres 
ult6rieurement au cours du processus de g6n6ration de code architectural. En eflfet, certaines 
technologies peuvent necessiter que les adaptateurs attendent d' avoir re9u toutes les requStes 
avaut de commencer a modifier le code produit par les generateurs. H se peut par exemple que 
les instructions produites doivent etre agencees dans im ordre different que celui-ci dans 
25 lequel elles se trouvaient dans la description d*application d'origine et que cet ordre depende 
de la nature de toutes les instructions concem6es. 

Les ad^tateurs serveurs sont pr6vus pour pouvoir recevoir successivraient plusieurs 
requ6tes de g^n^ration de code d'interface serveur pour plusieurs dependances, et ils 
choisissent, selon les contraintes des technologies qu'ils font conamuniquer et la manidre dont 
30 ils les font communiquer, s'ils produisent et inserent le code des interfaces g6n6rees au fiir et 
k mesure de la reception de ces requetes ou s'il doivent attendre le signal de fin de 
transmission des requetes emis par le r^partiteur pour inserer ce code. 

l.S) Adaptateurs clients 

35 Les adaptateurs clients pennettent de generer du code dans un ou plusieurs espaces 

technologiques donn6s. Ce code peut dtre int6gre au code produit par un g6n6rateur de code. 
Ce code joue le rdle d'interface client assurant la communication entre deux classes 
impliqu6es dans une d^pendance. Ce code est de pr^fdrence integr6 au code qu'a produit un 
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generateur pour la classe client impliquee dans cette dependance. Le code produit par cet 
adaptateur client s'interface avec le code, produit par un adaptateur serveur, iategre au code 
qu'a produit un g6n6rateur de code pour la classe serveur de cette dependance. 

Les adaptateurs clients sont munis d'un identifiant unique qui pennet de les designer 
5 dans la description de T architecture technique. 

lis indiquent dans quelle categoric d'interfaces lis se classent. Ces categories 
d'interfaces servent a determiner la compatibility de ces adaptateurs clients avec des 
adaptateurs serveurs. EUes sont definies librement par les adaptateurs clients et peuvent etre 
partag6es par plusieurs adaptateurs clients di£f6rents. 
10 Les adaptateurs clients indiquent quels sont le ou les g6n6rateurs de code dont ils sont 

capables de modifier le code produit pour y inserer le code de leurs interfeces clients ou de 
produire du code d'interfafage exteme au code produit par ce ou ces generateurs de code. 

Les adaptateurs clients doivent produire le code d'interface client k partir d'une 
dependance, des classes impliquees dans cette dependance et des references d'acces au code 
15 prodxiit pour ces classes par les generateurs de code correspondants a cette dependance. Les 
adaptateurs clients doivent comprendre et utiliser les marques de localisation laissees par les 
generateurs de code avec lesqiiels ils sont compatibles. 

Les ad£qptateurs clients doivent pouvoir recevoLr un signal de fin de transmission de 
requSte de g&ieration de code, leur indiquant qu'ils n*en recevront plus d'autres 
20 ult6rieurement au cours du processus de generation de code architectural. En efFet, certaines 
technologies peuvent necessiter que les adaptateurs attendent d' avoir re9u toutes les requetes 
avant de commencer a modifier le code produit par les g6nerateurs. 

Les adaptatevirs clients doivent pouvoir recevoir successivement plusieurs requetes de 
generation de code d'interface client pour plusieurs dependances, et ils choisissent, selon les 
25 contraintes des technologies qu'ils font commimiquer et la maniere dont ils les font 
communiquer, s'il doivent produire et insdrer le code des interfaces g€a€r6Gs au fur et ^ 
mesure de la reception de ces requetes ou s'il doivent attendre le signal de fin de transmission 
des requetes emis par le repartiteur pour inserer ce code. 

En fin de generation de code, les adaptateurs doivent avoir fait disparaltre du code les 
30 Ufiarques de localisation que les generateurs de code y ont place. 

1.9) Comparateur 

Le comparateur verifie la coherence entre les capacites de generation de code offerte par 
la description d'architecture et les besoins de la description d'application en terme de 
35 generation de code. H verifie done que les toutes les classes et dependances entre classes de 
rq>plication sont prises en charge par des espaces technologiques et adaptateurs adequats. 
Pour ce faire, le comparateur utilise notamment les services du filtre d'espaces 
technologiques. n permet de verifier les conditions suivantes : 
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- pour chacuTLe des classes que I'analj^eur de description d'application a decelees dans 
la description d'application, il verifie qu'il existe, dans la description de rarchitecture 
technique, un espace technologique prenant en charge ces classes ; 

- poiir chaque dependance, definie dans Triplication d6crite, entre une classe client et 
5 une classe serveur prises en charges par des espaces technologiques diflferents, il verifie 

qu'il existe un adaptateur serveur et un adaptateur client associes a chaque couple 
constitu6 d*un espace technologique prenant en charge la classe client et d'un espace 
technologique prenant en charge la classe serveur. 

En cas de lacunes dans la description de T architecture technique par rapport aux besoins 
10 de TappUcation qui entraine une inc^acit6 de generer son code, le comparateur 6met un 
message d'erreur en communiquant ces lacunes. 

MO^ Rfoartiteur 

Le repartiteur est charge de distribuer les classes et les dependances de la representation 
15 decomposee de la description de Tapplication, en fonction de I'architecture, sux les differents 
gen6rateurs de codes et adaptateiurs clients et adaptateurs serveurs, aiixsi que le prevoit le 
processus decrit au point 1.12). 

Si Tordre d'appel des differents adaptateurs client n'est pas indiflBSrent pour la 
generation de code, il determine cet ordre et appelle ensuite les adaptateurs clients concemes 
20 dans cet ordre. Si Tordre d'appel des differents adaptateurs serveur n'est pas indifferent pour 
la gen6ration de code, il determine cet ordre et appelle ensuite les adaptateurs serveur 
concemes dans cet ordre. Si Tordre d'appel des differents g6n6rateurs n'est pas indifferent 
pour la generation de code, il determine cet ordre et appelle ensuite les generateurs concemes 
dans cet ordre. 

25 

I.IV) Coordinateur 

Le coordinateur enchaine les appels des differents elements du generateur de code 
architectural d^crits ci-dessus. n suit le processus decrit au point 1.12) et il assure la 
transmission des paramfetres n6cessaires au fonctionnement du generateur de code 
30 architectural d'lm module d Tautre. Enfin, il assure Tinteraction entre le g6n6rateur de code 
architectural et le systeme ext6rieur (programme appelant ou utilisateur humain) qui en 
declenche le fonctionnement, en lui transmettant les erreurs et les messages eventuellement 
6mis par les diflf6rents modules. 

35 1.12) Fonc tinnnesment 

Nous aliens d^crire le fonctionnement du generateur de code architectural en relation 
avec la figure 4 qui illustre les 6tapes du fonctionnement 



wo 2004/013800 



PCT/EP2003/009311 



17 



Etape Init. Le systeme exterieiir declenche la generation de code architecturale par 
rintennediaire du coordinateur. II lui traosmet la liste des fichiers de description de 
Tapplication au format decrit au point 1.1) et des fichiers de description de rarchitecture au 
format decrit au point 1.3). Si on foumit plusieurs fichiers, on les foumit simultan6ment dans 
5 le cas ou leur presence k tous est necessaire pour interpreter la description. 

Etape 1 , Le coordinateur foumit k Tanalyseur de description d'application les fichiers 
de description de Tapplication exprimes dans le format du point LI). L'analyseur de 
description d' application analyse ces fichiers et renvoie la representation d6composee de 
Tapplication. En cas d'erreur 6niise lors de cette etape, le processus de gSn^ration s'airSte. 
10 Etape 2. Le coordinateur foiunit k Tanalyseur de description d'architecture les fichiers 

de description de Tarchitecture e>q)rimes dans le format du point 1.3). L'analyseiu" de 
description d'architecture analyse ces fichiers et renvoie la representation decomposee de 
rarchitecture, Au cours de cette etape l'analyseur de description d'architecture efPectue les 
taches suivantes :.. 

15 Etape 2.1. Si les generateurs de code sont parametrables, l'analyseur de 

description d'architecture soUicite le generateur de code de chaque espace 
technologique pour obtenir sa liste de paramdtres de fonctionnement. 
L'analyseur de description d'architecture v6rifie alors que le jeu de param^tres 
de fonctionnement de ces espaces technologiques ne definit de valeur que pour 

20 des parametres de cette liste. Dans tous les cas, il soUicite le generateur de code 

de chaque espace technologique pour en obtenir son jeu de parametre de filtrage. 
Etape 2.2 . Pour chaque espace technologique, l'analyseur de description 
d'architecture interroge le filtre d'espaces technologiques et invoque le service 
de v6rification de I'inclusion de deux jeux de paramfetres de filtrage, afin de 

25 v6rifier que le jeu de paramfetres de filtrage de I'espace technologique est bien 

inclus dans le jeu de paramdtres de filtrage du generateur. Une erreur est 6mise 
dans le cas contraire. 

Etape 2,3 ■ Pour chaque adaptateur serveur utilise dans I'architecture, l'analyseur 
de description d'architecture interroge cet adaptateur afin qu'il lui renvoie la 

30 liste des generateurs de code avec lesquels il est compatible, ainsi que la 

categorie dans l£iquelle il classe les interfaces qu'il genere. L'analyseur de 
description d'architecture verifie alors que pour chaque espace technologique 
dont I'adaptateur serveur doit r6aUser les interfaces serveur, le generateur de 
code associ6 a cet espace est bien present dans la liste de generateurs de code 

35 avec lesquels il est conipatible. Une errem est 6mise dans le cas contraire. 

Etape 2.4 . Pour chaque adaptateur client utilis6 dans I'architecture, l'analyseur 
de description d'architecture interroge cet adaptateur afin qu'il lui renvoie la 
liste des g^n^ateurs de code avec lesquels il est compatible ainsi que la 
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cat6gorie dans laquelie il classe les interfaces qu'il genera. L'analyseur de 
description d' architecture v6rifie alors que pour chaque espace technologique 
dont Tadaptateur client doit realiser les interfaces client, le g6n6rateur de code 
associe a cet espace est bien present dans la liste de generateurs de code avec 
5 lesquels il est compatible. H verifie aussi que Tad^tateur client en question 

produit bien des interfaces de la meme categoric que Tadaptateiu: serveur auquel 
il est associ6. Une erreur est 6mise dans le cas contraire. 
En cas d' erreur, le processus de g6n6ration s'airSte. 

Etape 3. Le coordinateur transmet la reprdsentation decompos6e de Tapplication et la 
10 representation decompos6e de Tarchitecture au comparateur. Le comparateur veiifie que les 
besoins de Tapplication en terme de generation de code sont pris en charge par Tarchitecture : 
Etane 3.1. Pour chaque classe d6finie dans replication, le comparateur 
interroge le filtre d'espaces technologiques et invoque le service de filtrage 
d'espaces technologiques, ajBn d'obtenir la liste des espaces technologiques de 
15 rarchitecture qui prennent en charge cette classe. Le comparateur verifie alors 

que pour chaque classe, cette liste est non vide. Dans le cas contraire, une erreur 
est 6mise. 

Le comparateur poursuit ensuite la d6tection des lacunes Sventuelles en verifiant que 
pour chaque dependance entre deux classes, Tarchitecture definit un couple d'adaptateurs 
20 client et serveur poxu: chaque paire d'espaces technologique qui prend en charge les deux 
classes de cette dependance. 

Si la comparaison se solde par ime erreur, la liste des lacimes d6tectees est transmise k 
I'appelant et le processus de generation s'arrete. 

Etape 4. Le coordinateur transmet au repartiteur la representation decomposee de 
25 Tapplication, la representation d6compos6e de Tarchitecture. Au cours de cette etape, le 
rSpartiteur effectue les t&ches suivantes : 

Btane 4.1. Pour chaque classe d6finie dans Tapplication, le repartiteur interroge 
le filtre d'espaces technologiques et invoque le service de filtrage d'espaces 
technologiques, afin d'obtenir la liste des espaces technologiques de 
30 rarchitecture qui preiinent en charge cette classe. 

Etape 4.2 . Pour chaque classe et pour chaque espace technologique prenant en 
charge cette classe, le repartiteur regroupe cette classe, ses d6pendances, en lui 
indiquant celles qui correspondent k des d6pendance enyers des classes prises en 
charge par des espaces technologiques diff&ents de Tespace considere, et les 
35 transmet au g&tierateur de code associ6 k cet espace. Le repartiteur lui transmet 

aussi le jeux de param^tres de fonctionnement qualifiant Tenvironnement 
mat^el et logiciel definis par cet espace technologique. 
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En retour, le r^paititeiir obtient les references d'accds aux codes sources 
produits. 

Etape 4.3. Le r^partiteur traite chaque dependance de la representation 
decomposee de la description d*application concemant deux classes prises en 
5 charge par des espaces technologiques difierents. 

Pour chacune de ces dependances, le rqjartiteur determine alors quels 
adaptateurs serveurs doivent prmdre en charge cette dependance, d'aprfes la 
description d' architecture. Pour une dependance entre une classe client et une 
classe serveur, les ad^tateurs serveurs en question sont ceux qui sont associSs i 

10 une dependance entre les espaces technologiques qui ont pris en charge la classe 

serveur et les espaces technologiques qui ont pris en charge la classe client. 
Pour chacune de ces dependances, le repartiteur transmet alors cette dependance, 
ainsi que les classes concem6es par cette dependance et les references d'acces 
axix codes sources associes k ces classes, a ces adaptateurs serveurs. 

15 Eta pe 4.4. Le repartiteur traite chaque dependance de la representation 

decomposee de la description d'appUcation concemant deux classes prises en 
charge par des espaces technologiques differents. 

Pour chacune de ces dependances, le repartiteur determine alors quels 
ad^tateurs chents doivent prendre eh charge cette dependance, d*apres la 

20 description d'architecture. Pour une d^endance entre une classe client et une 

classe serveur, les adaptateurs chents en question sont ceux qui sont associes a 
ime dependance entre les espaces technologiques qui ont pris en charge la classe 
serveur et les espaces technologiques qui ont pris en charge la classe client. 
Pour chacune de ces dependances, le repartiteur transmet alors cette dependance, 

25 ainsi que les classes concemees par cette dependance et les references d'acces 

aux codes sources associes k ces classes, k ces adaptateurs chent. 
Etape 4.5. Le repartiteur appelle chaque adaptateur serveur qui a ete sollicite 
durant retape 4,3 et lui envoie le signal de fin de transmission de requfite. Get 
appel se fait dsais Tordre requis si c'est n6cessaire, ainsi que le determine le 

30 repartiteur. 

Etape 4.6. Le repartiteur appelle chaque adaptateur chent qui a ete soUicite 
durant Tetape 4.4 et lui envoie le signal de fin de transmission de requSte. Get 
appel se fait dans Tordre requis si c*est necessaire, ainsi que le determine le 
repartiteur. 

35 En cas d'erreur, le processus de generation s'arrSte. 



2) Le lanpage de description de logiciel 
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2.1) OualiScatioD du laaeage selon rinvention. 

L- invention s'integre a un langage de description de logiciel. EUe lui pennet de d6crire 
un logiciel, existant ou en cours d' elaboration, sans que cette description ne contienne 
d'informations liees a la realisation pratique et technologique de ce logiciel (c'est-a-dire sans 
5 dependance envers les capacites specifiques d'un langage de programmation, d'lme plate- 
forme informatique materielle ou logicielle, ou plus generalement d'une technologie 
particuliere) mais en d6crivant de fapon concrete son fonctionnement. La description concrete 
du fonctionnement est realisee grace a la mise k disposition via le langage de notions 
concretes liees k la mise en ceuvre informatique pratique des applications. Ces notions sont 

10 destin6es k servir de base k la description de Tapplicatioa L*exploitation de ces notions et la 
clarification de leur fonctionnement et de leur role peuvent reposer sur leur association k une 
specification fonctionnelle et technique exprime dans un langage, qui pent meme Stre un 
langage naturel tel que le fi:an9ais, qui ne presume par des technologies employ6es pour la 
mettre en oeuvre. Citons en exemple des notions telles que celles de composant graphique, 

15 d'evenement de peripherique, de verification de donnee a partir d'une saisie dans I'interface 
honmae machine, de navigation, de stockage d'infonnation, de requete de recherche 
d'information dans une structure de stockage d'information, etc. 

L'absence, dans les descriptions faites k I'aide d*ua langage dot6 de Tinvention, 
d'informations li6es k la mise en oeuvre pratique et technique de I'application d6crite place ce 

20 langage, dans le diagramme de classement des langages de la figure 1, au dessus des langages 
de modeiisation abstraite. En effet, son niveau d'independance technologique est supeiieur 
puisqu'il ne souffire pas de leurs limitations dterites dans la partie consacrde a Tart antSrieur. 

En ce qui conceme Techelle horizontale du diagramme de la figure 1, le langage selon 
rinvention se place k droite des langages de quatrieme generation. En effet, si, tout comme 

25 eux, Tanalyse s6mantique automatique pent se reposer sur Tassurance de I'utilisation, par le 
programmeur, d'un cadre strict lors de la mod^lisation d'un service technique ou fonctionnel 
domie, la richesse des Elements disponibles pour decrire une application informatique est 
sup6rieure car elle est rendue independante d'une implementation sp6cifique et se concentre 
sur la description du service rendu. 

30 

2.2) Structure du laneaee selon rinvention 
2.2.1') Contexte 

L'invention repose sur im langage de description de logiciel, c'est-a-dire qu'il pennet de 
r6aliser une representation de tout ou partie d'une application logicielle. Le langage consid^re 
35 permet de d6fimr des classes dites classes standards. 

Ce langage pent definir des operations eiementaires permettant de decrire des 
algorithmes. 
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Ce langage supporte 6\'entuelleinent rh6ritage, c*est-i-dire la c^acite de definir des 
classes enrichissant d'autres classes. En cas de prise en charge de Th^ritage, le langage 
permet eventuellement de definir des classes abstraites, c'est-a-dire des classes qu'on ne pent 
instancier en objets et dont certaines methodes peuvent etre abstraites, c'est-a-dire des 
5 m6thodes dont le fonctionnement est non defini mais devra etre defini par les classes non 
abstraites qui h6ritent de ces classes abstraites. Le langage permet eventuellement de definir la 
portee des attributs, des methodes et des classes, c'est-i-dire la capacity d'acc^ des autres 
classes k ces diff6r6nts 61^ents selon leur position relative. Ce langage supporte 
eventuellement le polymorphisme, c'est-i-dire la capacity de manipuler une instance d'lme 
10 classe B h^ritant d'une classe A comme si elle 6tait ime instance de la classe A et, lors 
d'appels a des methodes de cette instance manipul6e conune ime instance d'une classe A, 
d'utiliser T implementation definie dans la classe B au lieu de Timplementation d^finie dans la 
classe A. Le lexique et la syntaxe de ce langage sont indifferents, du moment qu'ils respectent 
les contraintes etablies au paragraphe precedent. Ce langage pent eventuellement definir des 
15 types piimitife (par exemple, les bool6ens ou les entiers) qui ne sont pas necessairement des 
classes, et dans ce cas, Eventuellement definir des operations 616mentaires permettant de 
manipuler ces types primitifs. 

Le langage est defini par ime specification qui precise Tensemble de ces 61^ents et 
leurs conditions d'utilisation (lexique et syntaxe, et le cas Ech6ant, heritage, polymorphisme, 
20 classes abstraites, portee, types primitifs, operations elementaires). 

Enfin, le langage, tel qu'il est d6fini jusque la, ne foxunit pas et ne doit pas foumir de 
moyen d'accfes a des services techniques ou fonctioimels pouvant etre rendus par une 
quelconque plate-forme mat^rielle et logicielle susceptible d'accueillir un logiciel modelise a 
Taide de ce langage, hormis les operations elementaires sus-cit6es. En exemple de ces 
25 services auquel le langage ne doit pas donner accds k ce stade, citons : la capacit6 d*a£ficher 
des informations sur un p6riph6rique d'affichage ou d'impression, la reception d'evenements 
6mis par un periph6rique de commande comme le clavier ou la souris, la communication avec 
un service de stockage d*information, . . . 

30 " 2.2.2) L'invention ' ' 

L*invention consiste : 

- k enrichir le lexique et la syntaxe du langage de fa9on a le doter d'un format de 
description specifique pour des classes dites classes fondamentales, 

- etk associer optionnellCTient k ce langage une technique de definition de ces classes 
35 fondamentales. 

Ces classes sont dites fondamentales, car elles donnent, aux autres classes qui les 
utilisent, un acces k des services techniques ou fonctioimels fondamentaux, c*est-A-dire des 
services qui ne sont pas port^s directement par ces classes fondamentales via une definition 
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exprimfe gr§ce au langage lui-meme. Contrairement aux classes standards, le lien entre les 
classes fondamentales et leur definition est exteme au langage, D depend totalement d'une 
interpretation exterieure, par exemple par les outils utilisant cette invention, fond6e sur ime 
definition exterieine aux classes fondamentales. 
5 Le forma t de description des classes fondamentales. integre au langage, permet : 

1- de toujours pouvoir identifier une classe fondamentale comme telle, 

2- de toujours pouvoir distinguer une classe fondamentale d'une classe standard, 

3- de d6finir son identifiant imique, 

4- de d6finir ses attributs, qui ne peuvent avoir une port6e les rendant invisible a toute 
10 autre classe si le langage prevoit la ddfinition de la portee, 

5- de d6finir des methodes dites fondamentales sans en detailler le fonctionnement, qui 
sont par nature non abstraites, dans le cas oil les classes abstraites sont supportees, et 
qui ne peuvent avoir une part6e les rendant invisibles k toute autre classe si le 
langage prevoit la definition de la portee. Ces methodes fondamentales sont des 

15 methodes dont la definition se Itmite aux seules signatures, mais dont le 

fonctionnement n'est pas exprime grace au langage lui-meme et doit pourtant etre 
considere corome d6fini par tout syst&tne exploitant ce langage. 

La technique de definition des classes fondamentales impose, pour une classe 
20 fondamentale, de foiunir : 

1- sa description grace au langage tel qu'enrichi ci-dessus par le format de description 
des classes fondamentales, 

2- si I'heritage est supporte et dans ce cas de fa9on optionnelle, un lexique et une 
syntaxe, compatible avec le langage, sp6cifiques a cette classe, definissant le format 

25 utilis6 dans le langage pour d^crire les classes heritant de cette classe, 

3- si rinvention le prevoit, la specification fonctionnelle ou technique exhaustive des 
services rendus par cette classe, exprimee dans un langage indSpendant des 
technologies de mise en oeuvre, qui peut mSme Stre un langage naturel tel que le 
fran9ais. Cette specification ne doit pas presumer des technologies employees pour la 

30 iheftre en oeuvre. Elle doit clarifier le fonctionnement de toutes les methodes 

fondamentales de cette classe (cf. le dernier tiret au point ci-dessus consacre au 
format de description des classes fondamentales). H s'agit en resum6 de la 
s6mantique complete des points 1 et 2 de cette technique. Cette specification sera 
eventuellement traduite dans les langues des personnes susceptibles de realiser des 
35 outils prenant en charge cette classe, avec, pour chaque version, la reference de la 

langue en se basant pour cela sur un syst6me d'identification de langue d6fini. 
Le fonctionnement de ces classes fondamentales n'est done pas d6fini explicitement, de 
maniere algorithmique, en utilisant le langage lui-mSme, mais peut Stre defini seulement par 
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cette gj^cification fonctiomelle ou technique exprnn6e dans un langage indepoidaat des 
technologies de mise en oeuvre, tel qn'un langage natm-el comme le franfais par exemple. 

De plus, du fait de Tabsence expos6e au point 2.2.1) de moyen d'acces a des services 
techniques ou fonctionnels pouvant etre foumis par une quelconque plate-forme materielle ou 
5 logicielle, seules les classes fondamentales sont susceptibles de dormer accte k ces services. 

Les classes fondamentales sont elles-memes soumises aux lois de Pheritage si celui-ci 
est pr6sent dans le langage. Dans ce cas, on pent faixe h^riter une classe fondamentale d'une 
classe standard ou fondamentale, au mfeme titre qu'on peut faire heriter une classe standard 
d'lme classe standard ou fondamentale. 

10 

2.3"^ FonctionnemeTit 

Fonctionnement de s classes fondamentales. La mise en oeuvre des specifications des 
classes fondamentales est done entierement d6volue aux outils qui exploitent un langage selon 
rinvention. Ce sont ces outils qui realisent ou simulent le fonctionnement de ces classes, 

15 selon les besoins. 

Resvonsabilite du fon ctionnement des classes fondamentales . Les outils qui utilisent ou 
pennettent d'ejffectuer une description d*application avec un langage selon Tinvention et 
d^endant de classes fondamentales, doivent ainsi Stre con9us de fafon k prendre en compte 
les specifications de ces classes fondamentales lorsqu'ils doivent les interpreter. 

20 L'interpr6tation du r61e de ces classes fondamentales par ces outils repose done sur la 
conformite de ces outils avec les specifications de ces classes fondamentales. 

InteeraUon eventue lle de classes fondamentales a un langa ge. Un langage selon 
rinvention peut 6ventuellement integrer, dans sa specification elle-meme, un ensemble de ces 
classes fondamentales (dans ce cas non modifiables par Tutilisateur du langage) qui, une fois 

25 specifi^es selon la technique d6ciite au point 2.2.2, pemiettent aux descriptions de logiciels 
effectu6es grSce k ce langage et exploitant ces classes fondamentales de faire reposer ces 
logiciels sur les services de ces classes fondamentales. 

Extension d'un lansase var de s classes fondamentales lors de son utilisation. La 
technique de definition des classes fondamentales peut aussi 6tre rendue accessible aux 

30 utilisateurs du langage pour etendre les capacit^s du langage au-dela de ses specifications en y 
ajoutant de nouvelles classes fondamentales en plus des classes fondamentales eventuellement 
foumies avec le langage. Dans ce cas, il sera preferable de doter les outils exploitant ce 
langage d'un m6caiiisme d* extension qui permette aux utilisateurs d6finissant ces nouvelles 
classes fondamentales d'enrichir le fonctionnement de ces outils k Taide de modules 

35 additionnels afin que ces outils puissent prendre en compte dans le cadre de leur 
fonctionnement ces classes fondamentales confonn6mmt k la*sp6cification de ces classes. 

Intiret pour Vanalyse semantiaue a utomatiqu^, Les outils qui pemettront d'analyser les 
descriptions e£fectu6es gr§ce k un langage dot6 de cette invention seront capables d'identifier 
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des -services techniques ou fonctionnels par !a simple identification de Tutilisation des classes 
fondamratales dans la description d' application. Cette analyse sera ainsi faite sans ambiguite. 
En effet, la capacite d'lm outil d' analyse a foumir une analyse s6mantique automatique de ces 
descriptions repose seulement sur la connaissance, par le developpeur de cet outil, des 
5 sp6cifications des classes fondamentales, et non sur la deduction du role des classes utilisees 
par I'analyse algorithmique de la definition des classes decrites a Taide du langage, chose 
impossible aujourd'hui sans intervention humaine. 

Notion de definition exclusive et methode de renforcem&nt . Dans le cadre d'un langage 
selon I'invention, Texclusivit^, poss6d6e par les classes fondamentales, de la foumiture d'un 

10 service materiel ou logiciel donne reposant sur les specificit6s de la plate-fonne d'accueil du 
logiciel decrit, est assur6e par I'absence de ces services dans la definition du langage lui- 
meme. Par centre, pour les services purement algorithmiques, cette exclusivite n'est pas 
assixree par le langage, car il pennet la description d'algorithmes, et elle reposera done sur une 
contrainte exterieure. Cette exclusivite est Tassurance du determinisme complet de 1' analyse 

15 s&nantique automatique. Pour I'assurer, on concevra des outils produisant les descriptions de 
logiciels d6crits grSce k un langage dot6 de cette invention, de telle maniere qu'il soit 
impossible d'utiliser le langage pour decrire des algorithmes dans certains cas pris en charge 
par des classes fondamentales donnant acces k des services algorithmiques particuliers. 

Application a la generation de code. Panni les applications possibles de I'analyse 

20 semantique automatique permise par I'invention, on pent citer la generation de code vers des 
architectures techniques distribuees qui permet notanunent a un logiciel decrit a Taide d'un 
langage dote de cette invention d'etre portee vers n'importe quelle architecture technique 
foumissant les services decrits par les classes fondamentales utilisees dans la description de ce 
logiciel. En particulier, un langage selon I'invention pent avantageusement etre utilise avec un 

25 logiciel de g6n6ration de code selon Tinvention tel que du type d6crit au point 1) de la 
pr6sente description. 

30 Bien entendu, la presente invention ripest pas limitee aux exemples et au mode de 

realisation decrits et represents, mais elle est susceptible de nombreuses variantes accessibles 
a rhomme de Tart, 

Le logiciel de generation de code ainsi que le langage de description de logiciel selon 
rinvention procurent un gain de productivit6 du developpement des applications 
35 infoimatiques estim6 k pres de 70% par Tautomatisation d'un certain nombre de taches de 
programmation. L'mvention confSre aussi une liberie sans equivalent par rapport aux 
technologies utilis6es au cours du processus de developpement. Les technologies sont une 
cause majeure d'aleas et d'iacertitudes dans les projets infonnatiques. Cette liberie se traduit 
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done par une diminution des risques d'echecs at une meilleiire tenue des budgets et des d61ais. 
Le fait de ne d6finir qu'un modele d'application independant des technologies offre plusieuis 
avantages. D'abord, on n'a pas i considerer les contraintes techniques durant la modelisation, 
ce qui simplifie celle-ci. Ensuite cela pennet d'obtenir un modae plus proche des attentes des 
5 utilisateurs car non perverti par des questions qui n*ont rien a voir avec le fonctionnel. De ce 
fait la phase de concq>tion converge plus rapidement vers le resultat souhaite. De plus, il n'y 
a pas ensuite d'autres tiches a ex6cuter que la realisation de ce modele. En effet, on pent 
obtenir Tapplication int6graleinent r6alis6e techniquement sans intervention humaine autre 
que rindispensable conception technique. Cela est possible car on peut produire le code de 
10 programmation automatiquement a partir du modele qui contient toutes les informations 
n6cessaires pour decrire T application. 

Par ailleurs, Tinvention ameliore la fiabilite sur deux plans : la fiabilite de replication 
infonnatique obtenue et la fiabilite des previsions de d6roulement des projets. Concemant les 
applications informatiques, ils peuvent etre realises automatiquement par le logiciel de 

15 generation de code et ils ne comportent pas d'autres erreurs que celles introduites dans la 
conception fonctionnelle, et celles introdmtes par les g6nerateurs de code eux-memes. On 
peut raisonnablCTient partir du principe que ces demiferes seront moins nombreuses que celles 
produites par un programmeur humain car les schemas de programmation utilises peuvent Stre 
rddes sur un nombre de projets tres important. Et elles sont susceptibles de corrections et 

20 d' ameliorations incrementales au cours de la vie du produit, ce qui permettra de cq)italiser sur 
les progres en qualite. Quant aux erreurs introduites par la conception fonctionnelle, les 
modeles produits par application de Tinvention etant plus simple a valider, on peut estimer 
qu*elles seront moins nombreuses. 

Concemant le deroulement des projets, il faut noter que, dans de nombreux projets, les 

25 aspects techniques introduisent des difficultes insoupconnees de realisation et que certains 
choix d'architecture se reveient k I'usage desastreux pour la tenue des deiais et des budgets. 
Jusqu'alors on 6tait souvent contraint de les subir, car il 6tait trop tard pour revenir sur ce type 
de choix. Gr^ce a invention, les contraintes techniques sont assumees par les generateurs de 
code, et les choix d' architecture sont revisables. Le deroulement des projets subira done 

30 moins de heurts et s'ecartera moins des previsions. Enfin un autre element peut-§tre encore 
plus important qui vient regulierement perturber le deroulement des projets, est le changement 
des specifications fonctionnelles en cours de projet. C'est un evenement quasi-systematique et 
qui a des consequences lourdes sur les projets en terme de charge. Get inconvenient peut 6tre 
evite car il n'y a plus d'impact en terme de charge autre que la redefinition du module grSce k 

35 rinvention, et la transcription technique de ces modifications a im cout quasi-nul comme nous 
I'avons vu. Comme les specifications fonctionnelles sont validees avec les utilisateurs a partir 
de la simulation du modMe, les changements devraient de surcroit Stre moins frequents car 
une vaUdation en condition r6elle est plus fiable qu'une validation sur schemas ou maquette. 
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Un autre avantage de i'invsntion est la pos3ibilit6 de r6utiliser les developpcments. 
Cette possibility issue de rindfependance des technologies, pennet de capitaliser a Tinterieur 
d'un projet ou entre des projets ayant des 616ments fonctionnels en communs. Cela reduit 
notablement les couts de developpement et augmente la pertinence des applications produites 
5 par la validation croisee dont elles font ainsi Tobjet. A long tenne cette capacite de 
reutilisation peut se traduire par la possibilite de realiser un portage de T application. Cela 
pennet de migrer une application vers une nouvelle architecture technique, lorsque cela 
s'avere ndcessaire, sans surcotit important. 



10 
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REVBNDICATIQNS 



1. Un iogiciel de generation du code infonnatique d'au moins une partie d'une 
application infonnatique, dans lequel le Iogiciel genere ledit code infonnatique k partir d'une 
5 description de ladite partie de I'application infonnatique en repartissant ladite description 
entre plusieurs g6n6rateurs de code en fonction de regies de repartition modifiables, chaque 
g6nerateur de code traduisant la partie de ladite description qui lui est foumie, pour foumir au 
moins une partie dudit code informatique dans un langage respectif. 

10 2. Le Iogiciel selon la revendication 1, dteoniposant ladite description sous forme 

de classes d'objets, le Iogiciel r6partissant lesdites classes d'objets entre les generateurs de 
code en fonction desdites regies de repartition, chaque generateur de code traduisant les 
classes d'objets qui lui sont foumies, en ladite partie correspondante dudit code informatique. 

15 3. Le Iogiciel selon la revendication 2, decomposant en outre ladite description 

sous forme de d6pendances entre lesdites classes d'objets, et dans le cas d'une d6pendance 
entre deux classes d'objets traduites chacune par un g6n6rateur de code diflF6rent, le Iogiciel 
fait traiter ladite dSpendance par deux adaptateurs qui la traduisent chacun en un code 
informatique d'interfa9age des codes informatiques produits par lesdits generateurs de code 

20 pour lesdites deux classes d'objet. 

4. Le Iogiciel selon la revendication 3, dans lequel chacun des deux adaptatein-s 
prodxiit ledit code infonnatique d'interfa9age respectif pour une classe d'objets respective 
parmi lesdites deux classes d'objets, chacun des deux adaptateurs ins6rant de pr6f6rence le 

25 code infonnatique d'interfa9age respectif dans le code informatique produit par I'un desdits 
g6n&ateurs de code pour ladite classe d'objets pour laquelle Tadaptateur a produit ledit code 
informatique d'interfa9age. 

5. Le Iogiciel selon la revendication 3 ou 4, dans lequel lesdits deux adaptateurs 
30 devant traiter la d^pehdance sont choisis par le Iogiciel suivant des regies d'afifectation 

associant, pour le sens de la dependance desdites deux classes d'objets, un adaptateur 
correspondant k chacim des gen&ateurs de code traduisant lesdites deux classes d'objets, 
lesdites regies d' affectation 6tant modifiables. 

35 6. Le Iogiciel selon Tune quelconque des revendications Ik 5, g6n6rant ledit code 

informatique k partir de ladite description faite dans un langage organise en classes d'objets, 
dans lequel ledit langage permet de definir des premiferes classes donnant accds k des services 
techniques ou fonctionnels k foumir par les plates-formes informatiques mat6rielles et 
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logicielles recevant Tapplication infonnatique, lesdits services n'etant pas definissable-s par 
ledit langage, et les autres classes dudit langage ne peuvent acceder a im quelconque desdits 
services que par Tintermediaire desdites premieres classes. 



5 7. Le logiciel selon la revendication 6, repartissant ladite description entre les 

generateurs de code en fonction des regies de repartition associant au moins certaines desdites 
premidres classes ou desdites autres classes dudit langage k au moins xm desdits gen6rateurs 
de code, et dans le cas o\i la revendication 6 depend de la revendication 2, le logiciel 
decompose ladite description de pr6f6rence en premieres classes ou autres classes dudit 
10 langage. 

8. Le logiciel selon la revendication 6 ou 7 en ce qu'elles dependent de la 

revendication 5, dans lequel le logiciel decompose ladite description sous fomie de 
d^pendances entre lesdites classes d'objet a partir de dq)endances entre lesdites premieres 
15 classes ou autres classes dudit langage. 

9. Un langage de description de logiciel, notamment du type langage objet de 
mod^lisation d'application infonnatique, organise en classes pennettant de d6finir des 
premieres classes donnant acc^s a des services techniques ou fonctionnels k foumir par les 
20 plates-formes infonnatiques materielles et logicielles recevant Tapplication infonnatique, 
dans lequel : 

- lesdits services ne peuvent pas etre definis par ledit langage, et 

- les autres classes ne peuvent acc6der a un quelconque de ces services techniques ou 
fonctionnels que par rinteim6diaire desdites premieres classes. 

25 

10. Logiciel pennettant de construire gr^hiquement ou textuellement un module 
d' application infonnatique, notamment un modele d'interface homme-machine d'applicadon 
infonnatique et de foumir une description du module dans im langage selon la revendication 
9. 



30 
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